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Abstract 

Factors  such  as  the  unbounded  growth  in  technology,  as  well  as  the  desire  for  better,  faster, 
and  cheaper  products,  will  always  increase  the  pressure  for  advancing  time  transfer  systems  in 
the  foreseeable  future.  Timing  users  will  continually  need  systems  with  more  features  than 
before,  improved  robustness  over  previous  systems,  and  better  timing  precision,  stability,  and 
accuracy  than  ever. 

Often  lost  in  the  pursuit  of  timing  system  advancements  is  the  perspective  of  the  operator 
(user)  of  the  system  This  paper  addresses  elements  of  operations  that  are  essential  to  the 
cohesiveness  between  a  system  and  its  operator .  These  often  forgotten  elements  include  system 
training,  system  continuity,  operational  simplicity,  operator  responsibility,  and  common  sense  in 
implementation. 


INTRODUCTION 

“A  time  transfer  system  is  only  as  sophisticated  as  the  confidence  level  of  the  operator/user.”  How  often 
will  the  designers  of  time  transfer  systems  stop  to  reflect  on  this  simple  thought? 

The  great  technological  growth  the  world  is  currently  experiencing,  especially  since  the  dawn  of  the 
information  superhighway,  has  opened  the  door  for  countless  innovations  for  countless  products  in 
countless  time  transfer  applications.  Ultimately,  though,  if  a  customer  doesn’t  feel  comfortable  with  the 
operation  of  a  new  product,  the  countless  innovations  may  prove  to  be  more  counterproductive  than 
useful. 

Advances  in  the  determination,  maintenance,  and  distribution  of  PTTI  will  require  additional  insight  in 
the  needs  that  drive  such  advances,  and  will  also  require  improved  understanding  of  how  to  best 
implement  such  advances  with  minimal  risks  of  service  interruption. 

While  continuing  to  advance  on  the  technological  front  of  timing  systems,  we  must  not  forget  the  need  to 
ensure  that  the  operators  of  these  timing  systems  have  the  confidence  to  accept  the  systems  that  utilize 
state-of-the-art  advancements. 
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DESIGNING  FOR  OPERATIONS 

Typically,  the  two  major  factors  developers  take  into  consideration  in  the  design  of  a  timing  system  are 
performance  and  price — a  customer  will  show  interest  in  a  product  if  it  meets  timing  specifications, 
without  incurring  an  unacceptable  financial  tradeoff. 

While  not  interfering  with  these  two  important  goals,  the  design  of  a  timing  system  should  also 
incorporate  theory  about  the  realistic  operation  of  that  system.  How  a  system  should  theoretically  work 
only  matters  when  that  theory  is  allowed  to  operate  in  a  realistic  environment.  In  the  real  world,  life  isn’t 
perfect,  and  the  greatness  of  a  system  will  depend  on  how  it  performs  when  adversity  arises.  Timing 
systems  should  be  ready  to  respond  to  adversities — “nominal  case”  software  coding  will  eventually 
become  a  problem — at  the  worst  possible  time\  After  all,  a  PTTI  system  is  only  as  good  as  its  worst  day. 

System  Documentation 

Documenting  the  design  of  a  system  is  not  always  the  most  enjoyable  aspect  of  system  development. 
But,  for  many  reasons,  it  is  arguably  the  most  important  aspect.  Documentation  should  never  be 
considered  an  “afterthought”  of  system  development.  Rather,  the  designers  should  treat  documentation 
as  an  activity  parallel  to  such  activities  of  coding,  building,  and  testing. 

Documentation  is  essential  to  configuration  control  and  management.  When  a  customer  is  trying  to 
operate  a  system,  he/she  must  know  how  it’s  supposed  to  operate,  for  two  reasons:  a)  to  keep  the 
customer  protected  from  the  pain  of  undesirable  surprises,  and  b)  to  allow  the  customer  to  know  when 
something  isn’t  working  the  way  it’s  supposed  to,  and  thereby  allow  the  operator  to  intervene,  as 
appropriate. 

Documentation  ensures  accountability.  Many  timing  applications  involve  the  use  of  multiple  systems 
interconnected  in  a  typically  complicated  fashion.  By  understanding  each  component  of  a  system,  the 
user/operator  can  proactively  configure  his/her  application  such  that  no  components  will  interfere  with 
the  optimal  operation  of  the  other  components.  And,  when  something  doesn’t  work,  accountability, 
through  documentation,  expedites  the  anomaly  resolution  process.  In  essence,  documentation  can 
significantly  reduce  confusion,  and  can  also  help  to  resolve  disagreements  quickly. 

The  format  of  documentation  may  not  be  as  important  as  the  existence  of  documentation.  However,  the 
format  becomes  most  useful  when  it’s  geared  towards  optimal  absorption  of  content  by  the  reader,  who, 
again,  is  the  operator/user.  Different  applications  will  suggest  the  need  for  differing  formats.  Often, 
though,  similar  designs  can  benefit  from  the  use  of  similar  documentation  formats. 

The  purpose  of  documentation  is  to  describe  the  purpose  of  the  system,  for  the  perspective  of  the 
operator.  Documentation  provides  understandable  information,  in  an  efficient  manner,  to  the  system 
user.  Documentation  is  optimal  when  it  can  serve  the  knowledge  needs  of  the  user,  without 
overwhelming  the  user. 

System  Training 

In  many  military  operations,  the  operational  readiness  of  an  organizational  mission  literally  lives  or  dies 
in  the  execution  of  approved  standard  operating  procedures.  The  2d  Space  Operations  Squadron  (2 
SOPS),  responsible  for  command  and  control  of  all  operational  Global  Positioning  System  (GPS) 
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satellites,  is  perhaps  today’s  flagship  example  of  this  principle.  The  enormous  success  of  GPS  has 
resulted,  in  large  part,  from  certified  space  operations  crewmembers  who  exhibit  outstanding  checklist 
discipline,  and  to  the  others  within  the  squadron  who  facilitate  accurate  checklists  for  use  by  those 
operators. 

In  2  SOPS,  classroom  training  provides  only  preparation  for  on-the-job  training.  Many  can  relate  to  the 
necessity  for  having  this  understanding.  How  many  times  have  we  taken  a  C  class,  a  UNIX  Introduction, 
or  a  Windows  seminar,  only  to  find  out  that  once  we  get  back  to  our  desks,  we  require  more 
familiarization?  The  reason  for  this  is  simple.  Though  the  classes  we  pay  for  may  serve  as  excellent 
building  blocks  for  training,  each  particular  operational  environment  is  unique.  This  becomes 
increasingly  true  as  technologies  become  more  and  more  diversified.  As  such,  from  now  on,  truly  no  one 
can  reasonably  expect  any  classroom  training  to  completely  fill  the  whole  training  square.  Nothing  beats 
the  familiarization  and  orientation  that  on-the-job  training  provides. 

System  training  proves  itself  sufficient  if  it  can  serve  the  purpose  of  adequately  describing  how  a  system 
will  work,  but  truly  excels  when  it  describes  how  the  human  being  will  work  with  the  system. 

Operational  Continuity 

“The  more  something  changes . ”  You  know  the  rest.  This  statement  hits  home  more  than  we  realize. 

We  must  ask  ourselves,  “How  much  of  our  work  time  do  we  spend  creating  something  innovative, 
compared  to  the  time  we  spend  re-inventing  the  wheel?”  Many  of  us  share  the  experience  of  spending 
many  hours  re-working  something,  simply  because  the  originators  of  a  system  didn’t  take  the  time  to 
properly  envision  the  need  for  system  modularity. 

We  often  forget  the  importance  of  not  sacrificing  the  future  for  the  present.  Short-term  fixes  are  no 
substitute  for  long-term  solutions.  While  alleviating  symptoms  of  problems,  true  accomplishment  occurs 
when  we  can  identify  and  correct  the  causes  of  our  problems. 

Operational  Simplicity 

Simplicity  isn’t  always  that  simple.  Additional  system  features  can  add  robustness,  but  can  also  increase 
confusion.  The  more  bells  and  whistles  a  system  has,  the  less  each  one  may  be  understandable  to  the 
operator/user.  When  more  bells  and  whistles  sound,  the  higher  the  likelihood  of  operators  tending  to 
ignore  alarms,  simply  because  they’re  receiving  too  many. 

Often,  designers  will  add  features  that,  on  paper,  seem  to  show  potential  for  improving  operational 
performance.  However,  if  the  designers  don’t  have  a  solid  perspective  of  what  the  true  needs  of  the 
operator  are,  such  designers  may  end  up  complicating  matters  more  than  improving  matters. 

Such  confusion  often  finds  its  way  into  the  GPS  community.  One  particular  example  involves  the  classic 
accuracy  vs.  stability  debate.  To  many  experts  in  the  clock  community,  the  natural  intuition  is  to  believe 
that  the  more  accurate  the  clocks  at  the  GPS  monitor  stations,  the  better.  To  an  extent,  and  in  the  right 
context,  this  intuition  has  some  truth.  However,  what  many  in  the  timing  community  may  not  always 
understand  is  that  the  performance  of  GPS  actually  depends  much  more  on  stability  than  accuracy. 
Whether  in  navigation  or  time  transfer,  the  performance  of  GPS  is  largely  dependent  on  the  stability  of 
the  GPS  Composite  Clock.  The  stability  of  the  individual  frequency  standards  (in  both  monitor  stations 
and  satellites)  contributing  to  GPS  time  is  paramount  to  ensuring  Composite  Clock  stability.  Sacrificing 


63 


stability  for  absolute  frequency  or  time  accuracy  at  GPS  monitor  stations  can  actually  degrade  GPS 
performance  [1]. 

The  above  issue  is  merely  one  example.  Many  military  communication  systems  prefer  accuracy  over 
stability.  Many  digital  communication  systems,  such  as  local  area  networks  and  the  World  Wide  Web, 
may  not  care  too  much  about  accuracy  and  stability,  and  actually  may  care  more  about  simple 
operational  continuity.  Most  operators  of  PTTI  systems  look  for  the  right  combination  of  stability, 
accuracy,  and  operational  continuity.  The  mix  will  invariably  be  user-dependent. 

Often,  the  best  solution  to  a  challenge  will  be  the  least  intuitive,  but  the  simplest  in  design  and 
infrastructure.  Remember  the  KISS  principle;  Keep  It  Simple,  Scientist! 


OPERATIONS  IN  PRACTICE 

The  success  of  a  timing  system,  of  course,  doesn’t  merely  rest  on  its  design.  Yes,  operators  make  or 
break  a  well-designed  system.  Though  2  SOPS  commands  and  controls  a  superbly  designed  satellite 
system  (GPS),  using  sophisticated  navigation  and  time  transfer  software,  much  of  2  SOPS’s  operational 
success  over  the  years  is  directly  attributable  to  the  dedication  of  the  personnel  who  make  the  day-to-day 
difference  in  the  operational  availability  and  accuracy  of  GPS. 

Coordination 

The  importance  of  coordination  in  the  operation  of  a  system  is  as  follows;  our  activities  may  affect  more 
people  than  we  might  think — our  activities  might  be  more  important  than  we  may  think. 

How  many  times  in  our  corporate  world  have  we  felt  “cubicles  away,  yet  worlds  apart”?  How  often  do 
we  forget  that  simply  taking  the  time  to  walk  over  to  our  co-worker  could  help  prevent  a  problem  before 
it  can  even  occur?  How  simple  it  seems,  yet  how  uncommon  in  practice  it  occurs,  that  we  take  a  minute 
or  two  to  pick  up  the  phone  to  check  with  others  before  making  decisions  that  could  affect  them 
significantly? 

How  eager  many  are  to  offer  suggestions  and  recommendations,  but  how  often  are  we  too  lazy  to  ask  for 
them?  Ultimately,  if  we  are  working  on  something  that  others  will  eventually  use,  we  best  benefit  when 
we  actively  solicit  their  feedback.  And,  sometimes  simply  opening  the  door  for  the  opinions  of  others 
isn’t  enough— sometimes  we  absolutely  have  to  fight  for  feedback. 

The  problem  with  blind  spots  is  that  we  never  know  just  how  large  they  are!  We  must  be  careful  when 
we  make  assumptions.  When  we  assume,  what  we  truly  assume  is  responsibility  for  the  repercussions 
incurred  if  we’re  wrong!  One  of  the  most  common  mistakes  we  make  is  when  we  assume  that 
communication  lines  are  foolproof.  Unfortunately,  in  this  technological  age,  along  with  advances  in 
communications  comes  the  increased  likelihood  of  communication  breakdowns.  E-mails  can  get  lost, 
people  can  misinterpret  tone,  and  others  will  sometimes  make  incorrect  assumptions.  The  key  to 
alleviating  these  natural  problems  is  the  never-ending  conviction  to  always  follow  up. 
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Responsibility 

We  all  must  accept  various  levels  of  responsibility  in  our  particular,  unique  work  environments.  We 
must  be  reasonable,  not  just  to  others,  but  to  ourselves,  when  we  accept  responsibility,  explicitly  or 
implicitly.  We  must  set  reasonable  goals,  and  prioritize. 

By  accepting  responsibility  for  a  system,  we  must  think  not  only  in  terms  of  immediate  explicit 
responsibility,  but  also  in  terms  of  long-term ,  implicit  responsibility.  We  all  have  learned  international 
lessons  about  the  impacts  of  when  we  don’t  responsibly  act  with  foresight — we’ve  seen  many  time 
bombs — Y2K  is  perhaps  our  generation’s  most  egregious  example. 

Though  easier  said  than  done,  we  shouldn’t  ever  cover  up  problems;  rather  we  should  learn  from 
problems,  and  let  others  learn  from  them  as  well.  People  will  respect  us  more  in  the  long  term.  The 
more  one  tries  to  cover  up  a  problem,  the  less  likely  that  problem  will  be  able  to  experience  the  benefits 
of  a  solution ! 

When  we  take  control  of  a  project  (and  subsequently  take  credit  for  that  project),  we  must 
simultaneously  take  accountability  for  that  project.  Trust  is  integral  to  the  transfer  of  responsibility.  We 
can  best  earn  the  trust  of  others  when  we’re  willing  to  accept  the  accountability  that  parallels  the  control 
over  particular  projects.  If  we’re  going  to  take  advantage  of  people  to  further  our  careers,  we  should  first 
take  advantage  of  ourselves,  and  our  own  integrity. 

Common  Sense 

“It’s  realistic  to  be  optimistic,  but  even  more  optimistic  to  be  realistic.”  The  best  solution  for  a  problem 
will  most  likely  be  situation-dependent.  One  makes  the  best  progress  in  problem  solving  when  he/she 
approaches  and  examines  each  problem  uniquely. 

For  many  years,  many  in  the  timing  community  had,  via  empirical  analysis,  identified  what  appeared  to 
be  a  12-hour  timing  periodic  in  the  broadcast  GPS  signal.  Many  inferred  that  what  they  were  observing 
was  a  12-hour  periodic  in  GPS  time,  and  some  even  concluded  that  the  periodic  somehow  must  have 
been  due  to  some  quirk  in  the  GPS  steering  algorithm.  In  reality,  however,  as  presented  in  the  previous 
year’s  PTTI  Meeting,  the  2  SOPS  Ephemeris  Enhancement  Endeavor  (EEE)  was  able  to  reduce  the  12- 
hour  periodic  to  the  noise  level  of  the  GPS  Master  Control  Station  estimator,  strictly  by  improving 
satellite  ephemeris  and  solar  pressure  state  estimation  [2],  The  EEE  team  was  able  to  rule  out  the  GPS 
time  steering  algorithm  as  the  culprit  of  this  periodic,  and,  at  the  same  time,  for  the  most  part,  alleviate 
the  periodic,  without  even  touching  the  GPS  steering  algorithm. 

The  above  example  points  out  that,  when  one  takes  the  time  to  give  the  unique  attention  that  a  unique 
problem  deserves,  he/she  will  often  take  the  course  of  action  best  suited  for  his/her  long-term  interests, 
and  help  to  prevent  making  the  original  problem  worse.  Knee-jerk  reactions  can  result  in  injury!  Taking 
the  time  to  properly  assess  what’s  truly  going  on  can  ensure  safe,  progressive  improvements  in 
operations. 


CONCLUSION 


No  portion  of  the  above  text  truly  presents  anything  new  or  innovative.  The  thoughts  conveyed  in  the 
above  text  are  convictions  most  all  of  us  have,  whether  consciously  or  subconsciously.  Often,  a  natural 
progression  in  our  technological  revolution  is  to  become  preoccupied  with  the  technical  aspects  of  a 
great  system,  while  forgetting  to  consider  properly  the  operational  needs  of  the  user  of  the  system  itself. 
This  behavior  is  a  perfectly  natural  characteristic  of  human  nature  in  the  technological  age. 

Designers  of  PTn  systems  excel  by  staying  cognizant  of  the  requirements,  goals,  and  expectations  of  the 
operator.  Effective  lines  of  communication  are  essential.  Designers  who  fail  to  recognize  the  time- 
honored  “customer  first”  principle  will  fail  to  grow  and  may  eventually  fade  into  a  caretaker  status,  or 
much  worse. 

We  all  want  to  harness  the  benefits  of  the  many  technical  advances  that  are  occurring  literally  on  a  daily 
basis.  At  the  same  time,  however,  in  order  to  take  advantage  of  those  technically  advanced  systems,  we 
must  understand  how  to  bridge  the  gap  between  the  design  of  those  advances,  and  the  operational  use  of 
those  advances.  The  road  to  failure  is  paved  with  good  intentions.  The  road  to  success  is  best  driven  by 
confident,  responsible,  trained,  qualified  operators. 
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Questions  and  Answers 


MIHRAN  MIRANIAN  (USNO):  Steve,  you  might  want  to  comment  on  the  fact  that  UTC  did  not  run  off. 

STEVEN  HUTSELL  (USNO):  Yes,  good  point.  Mihran  pointed  out  the  fact  that  because  GPS  provides 
the  correction  term  for  the  GPS  minus  UTC  offset  in  Sub-Frame  4,  page  18  of  the  NAV  Message,  the  270- 
nanosecond  runoff  that  you  saw  did  not  directly  translate  into  270  nanoseconds  of  UTC  time  recovery  to 
users,  because  for  the  most  part  daily  updates  as  a  result  of  downloads  from  USNO  to  2SOPS  did  occur. 

So  that  at  least  it  minimized  the  degradation  and  thankfully  was  able  to  keep  the  very  top  blue  number 
under  28  nanoseconds,  which  is  the  specification. 

LT.  DAVID  CRATER  (2SOPS,  Schriever  AFB):  Steven,  I  wanted  just  to  ask  if  you  had  a  chance  to  get  a 
group  of  people  in  a  room,  people  that  designed  navigation  and  time-transfer  systems  for  solving  those 
types  of  problems.  What  w  ould  you  say  to  them  in  terms  of  improving  their  thinking  on  solving  these 
problems  and  incorporating  the  types  of  principles  that  you  have  talked  about,  as  opposed  to  solving  a  type 
of  problem  that  has  a  well  defined  set  of  things  that  need  to  be  addressed?  From  a  technical  point  of  view, 
how  would  you  tell  them  to  incorporate  the  types  of  operational  issues  that  you  have  talked  about? 

STEVEN  HUTSELL:  Obviously  I  am  going  to  bias  my  opinion  on  the  fact  that  I  have  spent  most  of  my 
time  being  an  operator  as  opposed  to  being  an  analyst  outside  of  operations.  Therefore,  my  opinion  is 
going  to  be  inherently  conservative;  and  part  of  that  opinion  was  formed  by  working  in  a  squadron,  winch 
you  are  now  in,  that  runs  very  efficiently  and  very  effectively  because  you  have  proven  procedures  and 
check  lists.  I  guess  my  biased  suggestion  w'ould  be  to  examine  the  problem  very  carefully  and  not  to  make 
hasty  decisions.  In  the  case  of  this  Colorado  Springs  event,  there  was  enough  time  to  get  enough  people 
together  as  a  “Tiger  Team”  Unfortunately,  for  various  reasons,  that  just  did  not  happen. 

We  are  not  in  a  business  where  we  have  to  make  decisions  so  quick  that  the  safety  of  the  world  is  going  to 
depend  on  it  over  a  few  minutes.  We  are  not  launching  ICBMs,  for  instance;  but,  at  the  same  time,  we  do 
not  have  that  much  time  to  resolve  a  problem.  In  the  case  of  GPS,  everything  is  geared  around  24-hour 
predictions;  uploads  are  done  24  hours  a  day;  downloads  from  USNO  are  done  once  every  24  hours.  That 
is  basically  the  general  time  frame  you  have  to  respond  in. 

The  answer  to  your  question  is:  Just  try  to  maintain  a  delicate  balance  of  getting  a  concrete  answer,  but 
not  taking  much  too  much  time  so  that  the  problem  lingers  on  -  if  that  is  any  help. 

JAMES  DeYOUNG  (USNO):  I  just  have  one  comment.  At  the  Naval  Observatory  we  have  had  a  number 
of  people  who  had  a  great  deal  of  experience  retire  in  the  last  few  years.  We  have  already  gone  through 
that  experience.  There  are  other  places  -  especially  in  this  room,  I  see  a  lot  of  people  that  have  been 
around  PTTT  for  a  long  time  who  will  potentially  be  retiring  in  the  near  future.  The  goal  is  that  basic 
knowledge  is  already  out  there,  but  there  is  still  no  replacement  for  experience  in  time  and  frequency. 
There  are  so  many  complex  systems  in  the  field  today  that  we  have  to  get  younger  people  experienced  in 
and  understanding  of  the  systems.  It  is  great  to  approximate  a  clock  wi  th  power-on  noise  and  all  of  these 
things;  but  in  the  data  I  look  at  day  to  day,  there  are  so  many  noise  processes  involved  together  that  the 
simple  models  are  not  going  to  be  sufficient.  In  my  opinion,  in  the  out-years,  when  you  go  to  two-way 
time  transfer  and  especially  GPS  carrier  phase  over  long  distances;  you  are  going  to  be  risking  a  lot. 

There  is  a  lot  of  stuff  going  on  that  is  scientifically  interesting  and  are  goals  for  bigger  budgets  in  the 
future  years. 
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STEVEN  HUTSELL.  Right.  It  enforces  the  tradeoff  of  how  much  performance  you  want  versus  how 
much  redundancy'  and  safety  you  have.  As  we  are  getting  more  technical  in  our  systems,  the  more  risks 
we  have  of  things  breaking  and  more  people  being  around  not  really  understanding  the  quickest  way  to 
solve  it.  It  is  a  dilemma. 
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